Clean Architecture 達人に学ぶソフトウェアの構造と設計
https://gyazo.com/96bdafc54e51fe5d6a206681feaabef3
ソフトウェアをメンテナンス可能な状態に保ち続け、ビジネスの変化やスケールに追従するための方法論
概念を頭に叩き込んだ上で実践あるのみ!
/icons/hr.icon
Notes
1章 設計とアーキテクチャ
早く進む唯一の方法は、うまく進むことである
後でキレイにする、は意味がない。市場は待ってくれないので後でキレイにすることはない。
2章 2つの価値のお話
ソフトウェア開発者のジレンマは、ビジネス責任者がアーキテクチャの重要性を理解していないこと
システムアーキテクトは、システムの機能よりも構造にフォーカスするものだ!!
3章 パラダイムの概要
3つのパラダイム : 「構造化プログラミング」 「オブジェクト指向プログラミング」 「関数型プログラミング」
パラダイムは規律をもたらした。つまり、より簡単に保守性の高いソフトウェアを作りやすくなっているということ
14章 コンポーネントの結合
変化した場合のダメージを最小限に抑えられるように依存関係を考えよ
いかなる場合も循環依存は避けるべき。循環依存を解消するためには、 「1. 依存関係逆転の法則」あるいは「2. 複数から依存させるための中間コンポーネントを作成する」
コンポーネントのトップダウンでの設計は極めて難しい。安定依存の原則 (常に安定度の高い方向に依存する) を考慮すべき。
20章 ビジネスルール
ビジネスルールとは、コンピュータで実現されているかどうかに限らず、お金を生み出すルールのこと。
エンティティは、システム内部のオブジェクトであり、重用なビジネスデータを有するもの。データを操作するビジネスルールを実装したI/Fが提供される。
ビジネスルールは、ソフトウェアが存在する理由だ!
22章 クリーンアーキテクチャ
この図に尽きる
https://gyazo.com/440f1325b3e77b85c2afc5e349826f93
ソースコードの依存性は、常に内側に向かっていかなければならない。つまり、円の内側は外側について何も知らない。
特に、外側で宣言された名前は内側のコードで触れてはいけない。
26章
Mainコンポーネントは究極的な詳細である。つまりは、OS以外にはこのコンポーネントに依存しているものはない。グローバルな要素を作成し、上位の抽象レイヤに処理を渡すのが仕事。
究極的な詳細 という概念が分かりづらい。
Mainには汚れ仕事が最も似合う。
30章
データベースはエンティティではなく詳細である。
データベースは道具であり、下位レベルの仕組みの話だ。優れたアーキテクトはシステムのアーキテクチャが下位レベルの仕組みに汚染されることを許さない。
RDBに引きづられ、例えばユースケースやビジネスルール、UIがリレーショナルデータ構造に縛られてしまうのはアーキテクチャとしては間違っている。
/icons/hr.icon